![[レポート] Powertools for AWS Lambda に入門する Supercharge Lambda functions with Powertools for AWS Lambda #DEV339](https://images.ctfassets.net/ct0aopd36mqt/3IQLlbdUkRvu7Q2LupRW2o/edff8982184ea7cc2d5efa2ddd2915f5/reinvent-2024-sessionreport-jp.jpg)
[レポート] Powertools for AWS Lambda に入門する Supercharge Lambda functions with Powertools for AWS Lambda #DEV339
2025.01.02資料
動画
スライド
セッション概要
Powertools for AWS Lambda の初心者の方向けに、どのようなことができるか２０分で説明するセッションです。
セッションにはサンプルをサーバレスアーキテクチャ、TypeScript で記載された Lambda を用いて、サンプルアーキテクチャで実際に発生が想定されるエラーの監視や対処方法を説明していきます。
セッションで用いられたアーキテクチャ
Powertools for AWS Lambda とは
AWSが管理、構築、保守しているオープンソースライブラリです。
可観測性、アーキテクチャパターン、および回復力に関するベストプラクティスを組み込んでいます。
Powertools for AWS Lambda
AWS公式の概要
AWS Lambda functions are crucial in cloud architectures but can be challenging due to potential failures and repetitive AWS-specific code. Powertools for AWS Lambda is a library that addresses these issues by enhancing observability, resiliency, and operational excellence in your Lambda functions. In this dev chat, explore the Powertools library’s capabilities and see how it can improve your Lambda functions by using it in a real-world application, helping you achieve a well-architected solution in AWS.
機械翻訳
AWS Lambda関数はクラウドアーキテクチャにおいて重要な役割を果たしますが、潜在的な障害やAWS固有のコードの繰り返しにより課題となる場合があります。Powertools for AWS Lambdaは、Lambda関数の可観測性、回復力、および運用の卓越性を向上させることでこれらの課題に対処するライブラリです。このデベロッパーチャットでは、Powertoolsライブラリの機能を探求し、実際のアプリケーションでの使用を通じて、AWSでの適切なアーキテクチャソリューションの実現を支援する方法について、Lambda関数をどのように改善できるかを見ていきます。
スピーカーについて
Raphael Manke
- ドイツで働いているITコンサルタント
- お客様のクラウドへの移行、特にサーバーレスの世界での移行を支援している
- AWSコミュニティビルダーでもある
セッションで説明したPowertools for AWS Lambda の機能
監視に必要なカスタムメトリクスの作成
----サンプルアーキテクチャのトラブルシューティング説明----
Lambda 関数の呼び出しがあり、DynamoDB テーブルと通信し、外部 API と通信し、Secrets Manager からシークレットを取得し、エラーが発生した場所を簡単に見つけることができます。これらの外部 API 呼び出しの1つが失敗したことがわかります。
AWS X-Ray を使用してトレースを行い、CloudWatch を使用してカスタムメトリクスでアラームを設定したことにより検知ができました。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
Metric クラス
監視に必要なカスタムメトリクスを簡単に作成が可能です。
CloudWatch にトレースメトリクスデータを出力するクラスを簡単にインスタンス化できます。クラスをインスタンス化したら、@Metric のような単純な関数を呼び出してデータポイントを追加し、メトリクスに名前を付け、データポイントの大きさを数値で指定できます。
Metrics 参考
Metric クラス 参考
例外のトレース情報の把握
----サンプルアーキテクチャのトラブルシューティング説明----
例外のトレース情報 からSecrets Manager でシークレット値が問題であることを把握して、更新することで問題を解決しました。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
Tracer クラス
Tracer クラスは、メトリクスの場合と同様にインスタンス化でき、たとえば、トレースを関連付けるための serviceName を指定できます。そして、SDK 呼び出しを行う場合は、Tracer クラスを使用して SDK 呼び出しをキャプチャできます。
captureAWSClient 関数を呼び出して、クライアントをラップします。これにより、SDK を介して行われたすべての API 呼び出しが、実際には X-Ray からキャプチャされます。
例外のトレース情報を簡単に把握できます。例で見たように、エラーを自動的にキャプチャしているため、問題のトラブルシューティングを行うときはいつでも、このスタックトレースとエラーメッセージがトレースビューに表示されます。
Tracer 参考
Tracer クラス 参考
Lambda 関数の結果のキャッシュ
----サンプルアーキテクチャのトラブルシューティング説明----
修正してから、回復するまでに時間がかかりました。それは、Powertools AWS Lambda の parameters ユーティリティを使用しているためです。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
Parameters utility
Parameters utility は System Manager、Secrets Manager、AppConfig、または DynamoDB のいずれかからパラメータを取得するための共通 API を備えたユーティリティです。しかし、便利な点は、これらのすべてのソースからデータを取得するための共通 API を備えているだけでなく、Lambda 関数で結果をキャッシュできることです。
Parameters utility 参考
部分的なバッチの失敗の報告
----サンプルアーキテクチャのトラブルシューティング説明----
システムは自動的に回復しました。しかし、この再試行は実際にはどこから来たのでしょうか？アーキテクチャで見たように、SQS メッセージを消費しています。
SQS 消費のベストプラクティスの1つは、部分的なバッチ障害を報告することです。キューからメッセージのフルバッチを消費している場合は、どのメッセージが成功したか、またはどのメッセージが失敗したかを報告する必要があります。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
BatchProcessor
BatchProcessor はLambda 呼び出しを取得し、これらのすべてのメッセージを反復処理し、メッセージIDと処理が成功したかどうかを追跡する必要があります。この処理が成功した場合、キューからメッセージを削除します。
Batch Processing 参考
BatchProcessor クラス 参考
冪等性
----サンプルアーキテクチャのトラブルシューティング説明----
システムを複数回再試行したため、以前に正常に実行されたAPI呼び出しが再試行された場合に再度実行されないようにする必要がありました。 そのため、外部サービスに書き込むこれらの外部API呼び出しの一部に冪等性を追加する必要がありました。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
idempotency ヘルパー
idempotency ヘルパーは有効期間内に再度呼び出すと、DynamoDB から古い結果が自動的に取得され、最初に発生したのと同じ位置で報告されます。また、同じ入力パラメータで同じ関数に対してすでに呼び出しが実行されているため、複数の呼び出しが同時に実行されている場合は、失敗します。
Idempotency参考
Function makeIdempotent
ロガー
----サンプルアーキテクチャのトラブルシューティング説明----
CloudWatch Insights クエリを実行し、注文IDで呼び出しに関係なくすべてのメッセージをフィルタリングすることで、成功を検証しました。これはどのように可能だったのでしょうか？構造化ロギングを使用して、CloudWatch Insights でデータを簡単にクエリできるようにしました。ログメッセージを渡す必要はありません。代わりに、検索結果をフィルタリングできる専用の属性があります。
----サンプルアーキテクチャのトラブルシューティング説明（ここまで）----
ロガー
Powertools AWS Lambda を使用すると、ロガーが無料で提供されます。これは、既存の console.log ステートメントのドロップイン代替です。そのため、これを使用することを強くお勧めします。ロガーインスタンスをインスタンス化するだけで、ログステートメントが必要な場合は、console ステートメントの代わりにロガーステートメントを使用するだけです。
CloudWatch Insights クエリを実行し、注文IDで呼び出しに関係なくすべてのメッセージをフィルタリングすることで、成功を検証しました。これはどのように可能だったのでしょうか？構造化ロギングを使用して、CloudWatch Insights でデータを簡単にクエリできるようにしました。ログメッセージを渡す必要はありません。代わりに、検索結果をフィルタリングできる専用の属性があります。
Logger 参考
言語
サンプルはTypeScript で記述されていますが、Powertools for AWS Lambda は他の言語でも利用できます。たとえば、Python、Java、.NET などです。
これらの言語はチーム全体で個別に開発されているため、機能はこれらの言語間で異なる場合があります。しかし、それでも、今日紹介した機能のほとんどは、これらのすべての言語で利用できます。
まとめ
Powertools for AWS Lambda というのをre:invent のセッションで初めて認識しました。
20 分で Powertools for AWS Lambda のおそらく主要な部分を網羅的に説明されてとても感動しました。
Workshopもあるようなので、これを気にもっと利用してみようと思います。
クラスメソッドでもPowertools for AWS Lambda について記事がありますので、ご参照ください！
